This invention relates generally to communications and, more particularly, to multipoint bridging, or conferencing, systems.
Generally speaking, multipoint conferencing can take a variety of forms over different types of networks such as packet networks, switched telephone networks, etc. For example, there is multipoint data conferencing in which users can confer about documents and share data In support of multipoint data conferencing, International Telecommunications Union (ITU) standard T.120 defines an umbrella set of protocols over, e.g., packet-based networks. In comparison, there is also multimedia conferencing in which users can participate in audiovisual meetings using, e.g., NetMeeting, which is available from Microsoft(copyright). Like ITU T.120, multimedia conferencing is specified in ITU H.323, which is another umbrella set of protocols covering transmission control protocol/Internet protocol (TCP/IP) connections over packet-based networks.
Multipoint bridging typically involves use of equipment from a bridging service provider for connecting the users (conferees) together. This equipment is typically referred to as a bridge or a multipoint control unit (MCU) that supports the necessary standards, e.g., ITU H.323 for multimedia. Equipment of this nature is referred to herein as a xe2x80x9cmultipoint server.xe2x80x9d (It is assumed for simplicity that the multipoint server supports industry standards for inter-operability with other equipment notwithstanding that the equipment may also support company-specific proprietary signaling.)
A multipoint server can be modeled as having a server capacity, N, which is the total number of conferees (users), that the server can, or should, support at any time. This capacity can be related to any one or more of a number of server characteristics. For example, the server capacity could be related to something as simple as the total number of server ports. In this case the server capacity is fixed, i.e., the server can support no more than N users. As another example, the server capacity could be related to a particular xe2x80x9cquality of servicexe2x80x9d (QoS) such as response time. Here, the server can support up to N users and guarantee a maximum response time. In this context, the server does not guarantee the committed QoS if more than N users access the server. In other words, once the a priori defined capacity is reached for a multipoint server, subsequent requests from additional users to join the conference(s) on that server are either approvedxe2x80x94thus probably causing performance degradation for all the usersxe2x80x94or are blocked.
As such, as conference (traffic) demands increase (especially during peak load times) it may be desirable (if not necessary) to increase the capacity of an existing multipoint server. One alternative is simply to replace this server with a bigger, i.e., more powerfulxe2x80x94and costlyxe2x80x94server. However, if the traffic is predictable, another alternative is to a priori cascade servers together to support a larger capacity. An illustration of a cascaded bridging configuration is shown in FIG. 1.
In this cascaded bridging configuration, the total needed capacity is a priori divided between a number of servers, 10-1 through 10-n, which each support a plurality of users. This cascaded bridging configuration, or bridge tree, is designed such that users on the same server primarily communicate with each other. For those situations where a user on one server, e.g., multipoint server 10-1, needs to communicate with a user on another server, e.g., multipoint server 10-n, communication is provided via multipoint server 20.
In contrast to the above-described approach for a priori designed cascaded bridging configurations, we have designed a system for dynamically cascading together a number of multipoint servers in order to increase system capacity.
In an embodiment, a bridging system comprises a router and a number of multipoint servers. For each user requesting to join a particular conference, the router routes the call to a particular server and, if necessary, causes additional servers to be added to increase the capacity for that conference. For example, upon receipt of a user request to join a conference associated with server A, the router first interrogates server A as to current spare capacity. If server A has additional capacity, the router routes the user to server A. However, if server A can not accommodate the user, the router causes server A to invite an additional serverxe2x80x94server Bxe2x80x94to join the conference. After server B joins the conference, the router routes the user to server B.